home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9421 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  63.2 KB

  1. Path: news.synopsys.com!jbuck
  2. From: jbuck@synopsys.com (Joe Buck)
  3. Newsgroups: gnu.g++.help,comp.lang.c++,news.answers,comp.answers
  4. Subject: FAQ for g++ and libg++, plain text version [Revised 29 Feb 1996]
  5. Supersedes: <g++FAQ_02_15_1996_texi@synopsys.com>
  6. Followup-To: poster
  7. Date: 1 Mar 1996 17:38:25 GMT
  8. Organization: Synopsys, Inc.
  9. Approved: news-answers-request@MIT.edu
  10. Expires: 1 Apr 1996 00:00:00 GMT
  11. Message-ID: <g++FAQ_03_01_1996_texi@synopsys.com>
  12. NNTP-Posting-Host: deerslayer.synopsys.com
  13. Originator: jbuck@deerslayer
  14.  
  15. Archive-name: g++-FAQ/plain
  16. Last-modified: 29 Feb 1996
  17. Frequency: bimonthly
  18.  
  19. [ this is the plain text version, the parent is the texinfo version ]
  20.  
  21.  
  22. FAQ for g++ and libg++, by Joe Buck (jbuck@synopsys.com)
  23. ********************************************************
  24.  
  25.    This is a list of frequently asked questions (FAQ) for g++ users;
  26. thanks to all those who sent suggestions for improvements.  Thanks to
  27. Marcus Speh for doing the index.  A hypertext version is available on
  28. the World Wide Web at `http://www.cygnus.com/misc/g++FAQ_toc.html'.
  29.  
  30.    Please send updates and corrections to the FAQ to
  31. `jbuck@synopsys.com'.  Please do *not* use me as a resource to get your
  32. questions answered; that's what gnu.g++.help is for and I don't have
  33. the time to support the net's use of g++.
  34.  
  35.    Many FAQs, including this one, are available on the archive site
  36. "rtfm.mit.edu"; see
  37. `ftp://rftm.mit.edu/pub/usenet/news.answers'.  This FAQ may be found in
  38. the subdirectory g++-FAQ.
  39.  
  40.    This FAQ is intended to supplement, not replace, Marshall Cline's
  41. excellent FAQ for the C++ language and for the newsgroup comp.lang.c++.
  42. Especially if g++ is the first C++ compiler you've ever used, the
  43. question "How do I do <X> with g++?" is probably really "How do I do
  44. <X> in C++?".  You can find this FAQ at
  45. `ftp://rtfm.mit.edu/pub/usenet/comp.lang.c++', or in HTML form at
  46. `http://cosmos2.phy.tufts.edu/~swinitzk/cppfaq/cppfa.htm'.
  47.  
  48. The latest poop - gcc-2.7.x
  49. ***************************
  50.  
  51.    This section is intended to describe more recent changes to g++,
  52. libg++, and such.  Some things in this section will eventually move
  53. elsewhere.
  54.  
  55.    *News:* as I write this (late February 1996) the gateway connecting
  56. the bug-g++ mailing list and the gnu.g++.bug newsgroup is broken.
  57. Please mail, do not post bug reports.
  58.  
  59. What's new in version 2.7.x of gcc/g++
  60. ======================================
  61.  
  62.    The current version of gcc/g++ is 2.7.2; the current libg++ is 2.7.1.
  63. These releases represent a great deal of work on the part of the g++
  64. maintainers to fix outstanding bugs and move the compiler closer to the
  65. current ANSI/ISO standards committee's working paper, including
  66. supporting many of the new features that have been added to the
  67. language.  I recommend that everyone read the NEWS file contained in
  68. the distribution (and that system administrators make the file
  69. available to their users).  I've borrowed liberally from this file here.
  70.  
  71.    If any features seem unfamiliar, you will probably want to look at
  72. the recently-released public review copy of the C++ Working Paper:
  73.    * PostScript and PDF (Adobe Acrobat): see
  74.      `ftp://research.att.com/dist/c++std/WP'.
  75.  
  76.    * HTML and ASCII versions: see `ftp://ftp.cygnus.com/pub/g++'.
  77.  
  78.    * World Wide Web: see `http://www.cygnus.com/misc/wp/'.
  79.  
  80.    Here are the main points:
  81.  
  82.    * As described above, the scope of variables declared in the
  83.      initialization part of a for statement has been changed; such
  84.      variables are now visible only in the loop body.  Use
  85.      `-fno-for-scope' to get the old behavior.  You'll need this flag
  86.      to build groff version 1.09, Ptolemy, and many others.
  87.  
  88.    * Code that does not use #pragma interface/implementation will most
  89.      likely shrink dramatically, as g++ now only emits the vtable for a
  90.      class in the translation unit where its first non-inline,
  91.      non-abstract virtual function is defined.
  92.  
  93.    * Support for automatic template instantiation has *not* been enabled
  94.      in the official distribution, due to a disagreement over design
  95.      philosophies.  But you can get a patch from Cygnus to turn it on;
  96.      retrieve the patch from
  97.      `ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz' to patch
  98.      gcc-2.7.2 (there are also patches for earlier gcc versions).
  99.  
  100.    * Support for exception handling has been improved; more targets are
  101.      now supported, and throws will use the RTTI mechanism to match
  102.      against the catch parameter type.  You must give the
  103.      `-fhandle-exceptions' to turn it on.  You must give the `-frtti'
  104.      switch to enable catching of derived exception objects with
  105.      handlers for the base exception class; if `-frtti' is not given,
  106.      only exact type matching works.
  107.  
  108.      Optimization is *not supported* with `-fhandle-exceptions'; no
  109.      need to report this as a bug.  You'll probably get an internal
  110.      compiler error if you try it.  (Q: is this better in 2.7.1?).
  111.  
  112.      For exception handling to work with 2.7.0 your CPU must be a SPARC,
  113.      RS6000/PowerPC, 386/486/Pentium, or ARM.  Release 2.7.1 added
  114.      support for the Alpha, and "m68k is rumored to work on some
  115.      platforms" and "VAX may also work" (according to Mike Stump).  It
  116.      still doesn't work on HP-PA or MIPS platforms.
  117.  
  118.    * Support for Run-Time Type Identification has been added with
  119.      `-frtti'.  This support is still in alpha; one major restriction
  120.      is that any file compiled with `-frtti' must include `<typeinfo>'
  121.      (*not* `typeinfo.h' as the NEWS file says).  Also, all code you
  122.      link with (including libg++) has to be built with `-frtti', so
  123.      it's still tricky to use.
  124.  
  125.    * Synthesis of compiler-generated constructors, destructors and
  126.      assignment operators is now deferred until the functions are used.
  127.  
  128.    * The parsing of expressions such as `a ? b : c = 1' has changed from
  129.      `(a ? b : c) = 1' to `a ? b : (c = 1)'.  This is a new C/C++
  130.      incompatibility brought to you by the ANSI/ISO standards committee.
  131.  
  132.    * The operator keywords and, and_eq, bitand, bitor, compl, not,
  133.      not_eq, or, or_eq, xor and xor_eq are now supported.  Use `-ansi'
  134.      or `-foperator-names' to enable them.
  135.  
  136.    * The `explicit' keyword is now supported.  `explicit' is used to
  137.      mark constructors and type conversion operators that should not be
  138.      used implicitly.
  139.  
  140.    * Handling of user-defined type conversion has been improved.
  141.  
  142.    * Explicit instantiation of template methods is now supported.  Also,
  143.      `inline template class foo<int>;' can be used to emit only the
  144.      vtable for a template class.
  145.  
  146.    * With -fcheck-new, g++ will check the return value of all calls to
  147.      operator new, and not attempt to modify a returned null pointer.
  148.  
  149.    * collect2 now demangles linker output, and c++filt has become part
  150.      of the gcc distribution.
  151.  
  152.    * Improvements to template instantiation: only members actually used
  153.      are instantiated.  (Actually this is not quite true: some inline
  154.      templates that are not successfully inlined may be expanded even
  155.      though they are not needed).
  156.  
  157. The GNU Standard C++ Library
  158. ============================
  159.  
  160.    The GNU Standard C++ Library (also called the "GNU ANSI C++ Library"
  161. in places in the code) is not libg++, though it is included in the
  162. libg++ distribution.  Rather, it contains classes and functions
  163. required by the ANSI/ISO standard.  The copyright conditions are the
  164. same as those for for the iostreams classes; the LGPL is not used.  See
  165. *Note legalities::.
  166.  
  167.    This library, libstdc++, is in the libg++ distribution in versions
  168. 2.6.2 and later.  It requires at least gcc 2.6.3 to build the
  169. libg++-2.6.2 version; use at least gcc 2.7.0 to build the libg++ 2.7.0
  170. version.  It contains a hacked-up version of HP's implementation of the
  171. Standard Template Library (see *Note Standard Template Library::).  I've
  172. successfully used this Standard Template Library version to build a
  173. number of the demos you'll see on various web pages.
  174.  
  175.    As of version 2.7.0, the streams classes are now in libstdc++
  176. instead of libg++, and libiostream is being phased out (don't use it).
  177. The g++ program searches this library.
  178.  
  179. Obtaining Source Code
  180. *********************
  181.  
  182. What is the latest version of gcc, g++, and libg++?
  183. ===================================================
  184.  
  185.    The latest "2.x" version of gcc/g++ is 2.7.2, released November 26,
  186. 1995.  The latest version of libg++ is 2.7.1, released November 12,
  187. 1995.
  188.  
  189.    Don't use 2.5.x, with x less than 5, for C++ code; there were some
  190. serious bugs that didn't have easy workarounds.  2.5.8 is the most
  191. solid 2.5.x release.  2.6.3 is the most solid 2.6.x release.
  192.  
  193.    For some non-Unix platforms, the latest port of gcc may be an earlier
  194. version (2.5.8, say).  You'll need to use a version of libg++ that has
  195. the same first two digits as the compiler version, e.g. use libg++
  196. 2.5.x (for the latest x you can find) with gcc version 2.5.8.
  197.  
  198.    The latest "1.x" version of gcc is 1.42, and the latest "1.x"
  199. version of g++ is 1.42.0.  While gcc 1.42 is quite usable for C
  200. programs, I recommend against using g++ 1.x except in special
  201. circumstances (and I can't think of any such circumstances).
  202.  
  203. How do I get a copy of g++ for Unix?
  204. ====================================
  205.  
  206.    First, you may already have it if you have gcc for your platform;
  207. g++ and gcc are combined now (as of gcc version 2.0).
  208.  
  209.    You can get g++ from a friend who has a copy, by anonymous FTP or
  210. UUCP, or by ordering a tape or CD-ROM from the Free Software Foundation.
  211.  
  212.    The Free Software Foundation is a nonprofit organization that
  213. distributes software and manuals to raise funds for more GNU
  214. development.  Getting your copy from the FSF contributes directly to
  215. paying staff to develop GNU software.  CD-ROMs cost $400 if an
  216. organization is buying, or $100 if an individual is buying.  Tapes cost
  217. around $200 depending on media type.  I recommend asking for version 2,
  218. not version 1, of g++.
  219.  
  220.    For more information about ordering from the FSF, contact
  221. gnu@prep.ai.mit.edu, phone (617) 542-5942 or anonymous ftp file
  222. `ftp://prep.ai.mit.edu/pub/gnu/GNUinfo/ORDERS' (you can also use one of
  223. the sites listed below if you can't get into "prep").
  224.  
  225.    Here is a list of anonymous FTP archive sites for GNU software.  If
  226. no directory is given, look in `/pub/gnu'.
  227.  
  228.      ASIA: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:/ftpsync/prep,
  229.      cair.kaist.ac.kr, ftp.nectec.or.th:/pub/mirrors/gnu
  230.      
  231.      AUSTRALIA: archie.oz.au:/gnu (archie.oz or archie.oz.au for ACSnet)
  232.      
  233.      AFRICA: ftp.sun.ac.za
  234.      
  235.      MIDDLE-EAST: ftp.technion.ac.il:/pub/unsupported/gnu
  236.      
  237.      EUROPE: irisa.irisa.fr, ftp.univ-lyon1.fr, ftp.mcc.ac.uk,
  238.      unix.hensa.ac.uk:/pub/uunet/systems/gnu, ftp.denet.dk,
  239.      src.doc.ic.ac.uk:/gnu, ftp.eunet.ch, nic.switch.ch:/mirror/gnu,
  240.      ftp.informatik.rwth-aachen.de, ftp.informatik.tu-muenchen.de,
  241.      ftp.win.tue.nl, ftp.funet.fi, ftp.denet.dk, ftp.stacken.kth.se,
  242.      isy.liu.se, ftp.luth.se:/pub/unix/gnu, ftp.sunet.se, archive.eu.net
  243.      
  244.      SOUTH AMERICA: ftp.unicamp.br, ftp.inf.utfsm.cl
  245.      
  246.      WESTERN CANADA: ftp.cs.ubc.ca:/mirror2/gnu
  247.      
  248.      USA: wuarchive.wustl.edu:/systems/gnu, labrea.stanford.edu,
  249.      ftp.digex.net:/pub/gnu, ftp.kpc.com:/pub/mirror/gnu, f.ms.uky.edu:/pub3/gnu,
  250.      jaguar.utah.edu:/gnustuff, ftp.hawaii.edu:/mirrors/gnu,
  251.      uiarchive.cso.uiuc.edu:/pub/gnu, ftp.cs.columbia.edu:/archives/gnu/prep,
  252.      col.hp.com:/mirrors/gnu, gatekeeper.dec.com:/pub/GNU,
  253.      ftp.uu.net:/systems/gnu
  254.  
  255.    The "official site" is prep.ai.mit.edu, but your transfer will
  256. probably go faster if you use one of the above machines.
  257.  
  258.    Most GNU utilities are compressed with "gzip", the GNU compression
  259. utility.  All GNU archive sites should have a copy of this program,
  260. which you will need to uncompress the distributions.
  261.  
  262.    UUNET customers can get GNU sources from UUNET via UUCP.  UUCP-only
  263. sites can get GNU sources by "anonymous UUCP" from site "osu-cis" at
  264. Ohio State University.  You pay for the long-distance call to OSU; the
  265. price isn't too bad on weekends at 9600 bps.  Send mail to
  266. uucp@cis.ohio-state.edu or osu-cis!uucp for more information.
  267.  
  268.    OSU lines are often busy.  If you're in the USA, and are willing to
  269. spend more money, you can get sources via UUCP from UUNET using their
  270. 900 number: 1-900-GOT-SRCS (900 numbers don't work internationally).
  271. You will be billed $0.50/minute by your phone company.
  272.  
  273.    Don't forget to retrieve libg++ as well!
  274.  
  275. Getting gcc/g++ for the HP Precision Architecture
  276. =================================================
  277.  
  278.    If you use the HP Precision Architecture (HP-9000/7xx and
  279. HP-9000/8xx) and you want to use debugging, you'll need to use the GNU
  280. assembler, GAS (version 2.3 or later).  If you build from source, you
  281. must tell the configure program that you are using GAS or you won't get
  282. debugging support.  A non-standard debug format is used, since until
  283. recently HP considered their debug format a trade secret.  Thanks to
  284. the work of lots of good folks both inside and outside HP, the company
  285. has seen the error of its ways and has now released the required
  286. information.  The team at the University of Utah that did the gcc port
  287. now has code that understands the native HP format.
  288.  
  289.    Some enhancements for the HP that haven't been integrated back into
  290. the official GCC are available from the University of Utah, site
  291. jaguar.cs.utah.edu.  You can retrieve sources and prebuilt binaries for
  292. GCC, GDB, binutils,and libg++; see the directory `/dist'.
  293.  
  294.    The libg++ version is actually the same as the FSF 2.6.  The Utah
  295. version of GDB can now understand both the GCC and HP C compiler debug
  296. formats, so it is no longer necessary to have two different GDB
  297. versions.
  298.  
  299.    I recommend that HP users use the Utah versions of the tools (see
  300. above), though at this point the standard FSF versions will work well.
  301.  
  302.    HP GNU users can also find useful stuff on the site geod.emr.ca in
  303. the `/pub/UNIX/GNU-HP' directory.
  304.  
  305.    Jeff Law is leaving the University of Utah, so the Utah prebuilt
  306. binaries may be discontinued.
  307.  
  308. Getting gcc/g++ binaries for Solaris 2.x
  309. ========================================
  310.  
  311.    "Sun took the C compiler out of Solaris 2.x.  Am I stuck?"
  312.  
  313.    No; prep.ai.mit.edu and its mirror sites provide GCC binaries for
  314. Solaris.  As a rule, these binaries are not updated as often as the
  315. sources are, so if you want the very latest version of gcc/g++, you may
  316. need to grab and install binaries for an older version and use it to
  317. bootstrap the latest version from source.
  318.  
  319.    The latest gcc binaries on prep.ai.mit.edu and its mirror sites are
  320. for version 2.5.6 for Solaris on the Sparc, and version 2.4.5 for
  321. Solaris on Intel 386/486 machines (the Solaris/Intel binaries seem to
  322. be gone from prep but still exist on some mirrors).
  323.  
  324.    There are also binaries for "gzip", the GNU compression utility,
  325. which you'll need for uncompressing the binary distribution.  On any GNU
  326. archive site, look in subdirectories `i486-sun-solaris2' or
  327. `sparc-sun-solaris2'.
  328.  
  329.    The ftp directory `ftp://ftp.quintus.com/pub/GNU' contains various
  330. GNU and freeware programs for Solaris2.X running on the sparc. These are
  331. packaged to enable installation using the Solaris "pkgadd" utility.
  332. These include GNU emacs 19.27, gcc (and g++) 2.6.0, Perl 4.036, and
  333. others.
  334.  
  335. How do I get a copy of g++ for (some other platform)?
  336. =====================================================
  337.  
  338.    As of gcc-2.7.x, there is Windows NT support in gcc.  Some special
  339. utilities are required.  See the INSTALL file from the distribution.
  340. If you're interested in GNU tools on Windows NT, see
  341. `http://www.cygnus.com/misc/gnu-win32/' on the WWW, or the anonymous
  342. FTP directory `ftp://ftp.cygnus.com/pub/gnu-win32/'.
  343.  
  344.    The standard gcc/g++ distribution includes VMS support.  Since the
  345. FSF people don't use VMS, it's likely to be somewhat less solid than
  346. the Unix version.  Precompiled copies of g++ and libg++ in
  347. VMS-installable form are available by FTP from mango.rsmas.miami.edu.
  348. See also `ftp://ftp.stacken.kth.se/pub/GNU-VMS/contrib', the site (in
  349. Sweden) which has gcc-2.5.8 and libg++-2.5.3.
  350.  
  351.    There are two different versions of gcc/g++ for MS-DOS: EMX and
  352. DJGPP.  EMX also works for OS/2 and is described later.  DJGPP is DJ
  353. Delorie's port.  It can be found on many FTP archive sites; its "home"
  354. is `ftp://oak.oakland.edu/pub/msdos/djgpp/'.
  355.  
  356.    The latest version of DJGPP is 1.12.maint4, a port of gcc-2.6.3 plus
  357. support software.  This version runs under Windows 3.x.  There's also a
  358. beta-2.00 version.
  359.  
  360.    FSF sells floppies with DJGPP on them; see above for ordering
  361. software from the FSF.
  362.  
  363.    DJGPP has its own newsgroup: `news:comp.os.msdos.djgpp'.
  364.  
  365.    For information on Amiga ports of gcc/g++, retrieve the file
  366. `ftp://prep.ai.mit.edu/pub/gnu/MicrosPorts/Amiga'
  367. or write to Markus M. Wild <wild@nessie.cs.id.ethz.ch>, who I hope
  368. won't be too upset that I mentioned his name here.
  369.  
  370.    A port of gcc to the Atari ST can be found at
  371. `ftp://atari.archive.umich.edu/atari/Gnustuff/Tos' along with many
  372. other GNU programs.  This version is usually the same as the latest FSF
  373. release.  See the "Software FAQ" for the Usenet group
  374. "comp.sys.atari.st" for more information.
  375.  
  376.    There are two different ports of gcc to OS/2, the so-called EMX port
  377. (which also runs on MS-DOS), and a port called "gcc/2".  The latter
  378. port is no longer supported, since the EMX port includes all of its
  379. functionality.  The EMX port's C library attempts to provide a
  380. Unix-like environment.  For more information ask around on
  381. "comp.os.os2.programmer.misc".
  382.  
  383.    The EMX port is available by FTP from
  384.  
  385.      ftp://ftp.uni-stuttgart.de/pub/systems/os2/emx-0.9a
  386.      ftp://src.doc.ic.ac.uk/pub/packages/os2/unix/emx09a
  387.      ftp://ftp.informatik.tu-muenchen.de/pub/comp/os/os2/devtools/emx+gcc
  388.  
  389.    Eberhard Mattes did the EMX port.  His address is
  390. mattes@azu.informatik.uni-stuttgart.de.
  391.  
  392.    I'm looking for more information on gcc/g++ support on the Apple
  393. Macintosh.  Until recently, this FAQ did not provide such information,
  394. but FSF is no longer boycotting Apple as the League for Programming
  395. Freedom boycott has been dropped.
  396.  
  397.    Versions 1.37.1 and 2.3.3 of gcc were ported by Stan Shebs and are
  398. available at
  399. `ftp://ftp.cygnus.com/pub/mac'
  400.  
  401.    They are both interfaced to MPW.  Stan is working on a version using
  402. the current (post-2.7) sources, contact him directly (shebs@cygnus.com)
  403. for more information.
  404.  
  405. But I can only find g++-1.42!
  406. =============================
  407.  
  408.    "I keep hearing people talking about g++ 2.7.2 (or some other number
  409. starting with 2), but the latest version I can find is g++ 1.42.  Where
  410. is it?"
  411.  
  412.    As of gcc 2.0, C, C++, and Objective-C as well are all combined into
  413. a single distribution called gcc.  If you get gcc you already have g++.
  414. The standard installation procedure for any gcc version 2 compiler will
  415. install the C++ compiler as well.
  416.  
  417.    One could argue that we shouldn't even refer to "g++-2.x.y" but it's
  418. a convention.  It means "the C++ compiler included with gcc-2.x.y."
  419.  
  420. Installation Issues and Problems
  421. ********************************
  422.  
  423. I can't build g++ 1.x.y with gcc-2.x.y!
  424. =======================================
  425.  
  426.    "I obtained gcc-2.x.y and g++ 1.x.y and I'm trying to build it, but
  427. I'm having major problems.  What's going on?"
  428.  
  429.    If you wish to build g++-1.42, you must obtain gcc-1.42 first.  The
  430. installation instructions for g++ version 1 leave a lot to be desired,
  431. unfortunately, and I would recommend that, unless you have a special
  432. reason for needing the 1.x compiler, that C++ users use the latest
  433. g++-2.x version, as it is the version that is being actively maintained.
  434.  
  435.    There is no template support in g++-1.x, and it is generally much
  436. further away from the ANSI draft standard than g++-2.x is.
  437.  
  438. OK, I've obtained gcc; what else do I need?
  439. ===========================================
  440.  
  441.    First off, you'll want libg++ as you can do almost nothing without it
  442. (unless you replace it with some other class library).
  443.  
  444.    Second, depending on your platform, you may need "GAS", the GNU
  445. assembler, or the GNU linker (see next question).
  446.  
  447.    Finally, while it is not required, you'll almost certainly want the
  448. GNU debugger, gdb.  The latest version is 4.15.1, released November 4,
  449. 1995.  Other debuggers (like dbx, for example) will normally not be
  450. able to understand at least some of the debug information produced by
  451. g++.
  452.  
  453. Should I use the GNU linker, or should I use "collect"?
  454. =======================================================
  455.  
  456.    First off, for novices: special measures must be taken with C++ to
  457. arrange for the calling of constructors for global or static objects
  458. before the execution of your program, and for the calling of
  459. destructors at the end.  (Exception: System VR3 and System VR4 linkers,
  460. Linux/ELF, and some other systems support user-defined segments; g++ on
  461. these systems requires neither the GNU linker nor collect.  So if you
  462. have such a system, the answer is that you don't need either one).
  463.  
  464.    If you have experience with AT&T's "cfront", this function is
  465. performed there by programs named "patch" or "munch".  With GNU C++, it
  466. is performed either by the GNU linker or by a program known as
  467. "collect".  The collect program is part of the gcc-2.x distribution;
  468. you can obtain the GNU linker separately as part of the "binutils"
  469. package.  The latest version of binutils is 2.5.2, released November 2,
  470. 1994.
  471.  
  472.    (To be technical, it's "collect2"; there were originally several
  473. alternative versions of collect, and this is the one that survived).
  474.  
  475.    There are advantages and disadvantages to either choice.
  476.  
  477.    Advantages of the GNU linker:
  478.  
  479.    It's faster than using collect - collect basically runs the standard
  480. Unix linker on your program twice, inserting some extra code after the
  481. first pass to call the constructors.  This is a sizable time penalty
  482. for large programs.  The GNU linker does not require this extra pass.
  483.  
  484.    GNU ld reports undefined symbols using their true names, not the
  485. mangled names (but as of 2.7.0 so does collect).
  486.  
  487.    If there are undefined symbols, GNU ld reports which object file(s)
  488. refer to the undefined symbol(s).
  489.  
  490.    As of binutils version 2.2, on systems that use the so-called "a.out"
  491. debug format (e.g. Suns running SunOS 4.x), the GNU linker compresses
  492. the debug symbol table considerably.
  493.  
  494.    Advantages of collect:
  495.  
  496.    If your native linker supports shared libraries, you can use shared
  497. libraries with collect.  This used to be a strong reason *not* to use
  498. the GNU linker, but recent versions of GNU ld support linking with
  499. shared libraries on many platforms, and creating shared libraries on a
  500. few (such as Intel x86 systems that use ELF object format).
  501.  
  502.    Note: using existing shared libraries (X and libc, for example) works
  503. very nicely.  Generating shared libraries from g++-compiled code is
  504. another matter, generally requiring OS-dependent tricks if it is
  505. possible at all.  But progress has been made recently.
  506.  
  507.    As of 2.7.0, building C++ shared libraries should work fine on
  508. supported platforms (HPUX 9+, IRIX 5+, DEC UNIX (formerly OSF/1), SunOS
  509. 4, Linux/ELF and all targets using SVR4-style ELF shared libraries).
  510.  
  511.    However, as of libg++ 2.6.2, the libg++ distribution contains some
  512. patches to build libg++ as a shared library on some OSes (those listed
  513. above).  Check the file `README.SHLIB' from that distribution.
  514.  
  515.    The GNU linker has not been ported to as many platforms as g++ has,
  516. so you may be forced to use collect.
  517.  
  518.    If you use collect, you don't need to get something extra and figure
  519. out how to install it; the standard gcc installation procedure will do
  520. it for you.
  521.  
  522.    In conclusion, I don't see a clear win for either alternative at this
  523. point.  Take your pick.
  524.  
  525. Should I use the GNU assembler, or my vendor's assembler?
  526. =========================================================
  527.  
  528.    This depends on your platform and your decision about the GNU
  529. linker.  For most platforms, you'll need to use GAS if you use the GNU
  530. linker.  For some platforms, you have no choice; check the gcc
  531. installation notes to see whether you must use GAS.  But you can
  532. usually use the vendor's assembler if you don't use the GNU linker.
  533.  
  534.    The GNU assembler assembles faster than many native assemblers;
  535. however, on many platforms it cannot support the local debugging format.
  536.  
  537.    If you want to build shared libraries from gcc/g++ output and you
  538. are on a Sun, you must *not* use GNU as, as it cannot do
  539. position-independent code correctly yet.  *Note*: I've been told that
  540. this problem has been fixed in the most recent binutils release, but I
  541. haven't checked this yet.
  542.  
  543.    On HPUX or IRIX, you must use GAS (and configure gcc with the
  544. `--with-gnu-as' option) to debug your programs.  GAS is strongly
  545. recommended particularly on the HP platform because of limitations in
  546. the HP assembler.
  547.  
  548.    The GAS distribution has recently been merged with the binutils
  549. distribution, so the GNU assembler and linker are now together in this
  550. package (as of binutils version 2.5.1).
  551.  
  552. How do I use the new repository code?
  553. =====================================
  554.  
  555.    Because there is some disagreement about the details of the template
  556. repository mechanism, you'll need to obtain a patch from Cygnus Support
  557. to enable the 2.7.2 repository code.  You can obtain the patch by
  558. anonymous FTP: `ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz'.
  559.  
  560.    There are patches for 2.7.0 and 2.7.1 in the same directory, though
  561. if you're going to rebuild the compiler you should use the latest one.
  562.  
  563.    After you've applied the patch, the `-frepo' flag will enable the
  564. repository mechanism.  The flag works much like the existing
  565. `-fno-implicit-templates' flag, except that auxiliary files, with an
  566. `.rpo' extension, are built that specify what template expansions are
  567. needed.  At link time, the (patched) collect program detects missing
  568. templates and recompiles some of the object files so that the required
  569. templates are expanded.
  570.  
  571.    Note that the mechanism differs from that of cfront in that template
  572. definitions still must be visible at the point where they are to be
  573. expanded.  No assumption is made that `foo.C' contains template
  574. definitions corresponding to template declarations in `foo.h'.
  575.  
  576.    Jason Merrill writes: "To perform closure on a set of objects, just
  577. try to link them together.  It will fail, but as a side effect all
  578. needed instances will be generated in the objects."
  579.  
  580. Known bugs and problems with the repo patch
  581. ===========================================
  582.  
  583.    "The `-frepo' won't expand templated friend functions!"
  584.  
  585.    This is a known bug; currently you'll have to explicitly instantiate
  586. friend functions when using `-frepo' due to this bug (in 2.7.0 through
  587. 2.7.2 at least).
  588.  
  589.    With earlier versions of the repo patch, there was a bug that happens
  590. when you have given a quoted command line switch, something like
  591.  
  592.      -D'MESSAGE="hello there"'
  593.  
  594.    The repo code tries to recompile files using the same flags you
  595. originally specified, but doesn't quote arguments that need quoting,
  596. resulting in failures in some cases.  This is no longer a problem with
  597. the 2.7.2 patch.
  598.  
  599. Should I use the GNU C library?
  600. ===============================
  601.  
  602.    At this point in time, no.  The GNU C library is still very young,
  603. and libg++ still conflicts with it in some places.  Use your native C
  604. library unless you know a lot about the gory details of libg++ and
  605. gnu-libc.  This will probably change in the future.
  606.  
  607. Global constructors aren't being called
  608. =======================================
  609.  
  610.    "I've installed gcc and it almost works, but constructors and
  611. destructors for global objects and objects at file scope aren't being
  612. called.  What did I do wrong?"
  613.  
  614.    It appears that you are running on a platform that requires you to
  615. install either "collect2" or the GNU linker, and you have done neither.
  616. For more information, see the section discussing the GNU linker (*Note
  617. use GNU linker?::).
  618.  
  619.    On Solaris 2.x, you shouldn't need a collect program and GNU ld
  620. doesn't run.  If your global constructors aren't being called, you may
  621. need to install a patch, available from Sun, to fix your linker.  The
  622. number of the "jumbo patch" that applies is 101409-03.  Thanks to
  623. Russell Street (r.street@auckland.ac.nz) for this info.
  624.  
  625.    It appears that on IRIX, the collect2 program is not being installed
  626. by default during the installation process, though it is required; you
  627. can install it manually by executing
  628.  
  629.      make install-collect2
  630.  
  631.    from the gcc source directory after installing the compiler.  (I'm
  632. not certain for which versions of gcc this problem occurs, and whether
  633. it is still present).
  634.  
  635. Strange assembler errors when linking C++ programs
  636. ==================================================
  637.  
  638.    "I've installed gcc and it seemed to go OK, but when I attempt to
  639. link any C++ program, I'm getting strange errors from the assembler!
  640. How can that be?"
  641.  
  642.    The messages in question might look something like
  643.  
  644.      as: "/usr/tmp/cca14605.s", line 8: error: statement syntax
  645.      as: "/usr/tmp/cca14605.s", line 14: error: statement syntax
  646.  
  647.    (on a Sun, different on other platforms).  The important thing is
  648. that the errors come out at the link step, *not* when a C++ file is
  649. being compiled.
  650.  
  651.    Here's what's going on: the collect2 program uses the Unix "nm"
  652. program to obtain a list of symbols for the global constructors and
  653. destructors, and it builds a little assembly language module that will
  654. permit them all to be called.  If you're seeing this symptom, you have
  655. an old version of GNU nm somewhere on your path.  This old version
  656. prints out symbol names in a format that the collect2 program does not
  657. expect, so bad assembly code is generated.
  658.  
  659.    The solution is either to remove the old version of GNU nm from your
  660. path (and that of everyone else who uses g++), or to install a newer
  661. version (it is part of the GNU "binutils" package).  Recent versions of
  662. GNU nm do not have this problem.
  663.  
  664. Other problems building libg++
  665. ==============================
  666.  
  667.    "I am having trouble building libg++.  Help!"
  668.  
  669.    On some platforms (for example, Ultrix), you may see errors
  670. complaining about being unable to open dummy.o.  On other platforms
  671. (for example, SunOS), you may see problems having to do with the type
  672. of size_t.  The fix for these problems is to make libg++ by saying
  673. "make CC=gcc".  According to Per Bothner, it should no longer be
  674. necessary to specify "CC=gcc" for libg++-2.3.1 or later.
  675.  
  676.    "I built and installed libg++, but g++ can't find it.  Help!"
  677.  
  678.    The string given to `configure' that identifies your system must be
  679. the same when you install libg++ as it was when you installed gcc.
  680. Also, if you used the `--prefix' option to install gcc somewhere other
  681. than `/usr/local', you must use the same value for `--prefix' when
  682. installing libg++, or else g++ will not be able to find libg++.
  683.  
  684.    The toplevel Makefile in the libg++ 2.6.2 distribution is broken,
  685. which along with a bug in g++ 2.6.3 causes problems linking programs
  686. that use the libstdc++ complex classes.  A patch for this is available
  687. from `ftp://ftp.cygnus.com//pub/g++/libg++-2.6.2-fix.gz'.
  688.  
  689. But I'm *still* having problems with `size_t'!
  690. ==============================================
  691.  
  692.    "I did all that, and I'm *still* having problems with disagreeing
  693. definitions of size_t, SIZE_TYPE, and the type of functions like
  694. `strlen'."
  695.  
  696.    The problem may be that you have an old version of `_G_config.h'
  697. lying around.  As of libg++ version 2.4, `_G_config.h', since it is
  698. platform-specific, is inserted into a different directory; most include
  699. files are in `$prefix/lib/g++-include', but this file now lives in
  700. `$prefix/$arch/include'.  If, after upgrading your libg++, you find that
  701. there is an old copy of `_G_config.h' left around, remove it, otherwise
  702. g++ will find the old one first.
  703.  
  704. Do I need to rebuild libg++ to go with my new g++?
  705. ==================================================
  706.  
  707.    "After I upgraded g++ to the latest version, I'm seeing undefined
  708. symbols."
  709.  
  710.    or
  711.  
  712.    "If I upgrade to a new version of g++, do I need to reinstall
  713. libg++?"
  714.  
  715.    As a rule, the first two digits of your g++ and libg++ should be the
  716. same.  Normally when you do an upgrade in the "minor version number"
  717. (2.5.7 to 2.5.8, say) there isn't a need to rebuild libg++, but there
  718. have been a couple of exceptions in the past.
  719.  
  720. Trouble installing g++ and libg++ on Linux
  721. ==========================================
  722.  
  723.    "I've downloaded the latest g++ and libg++ and I'm trying to install
  724. them on Linux, and I'm having lots of problems."
  725.  
  726.    FSF releases of libg++ won't install on Linux unchanged, since Linux
  727. uses are part of the libio library from libg++ for its standard C
  728. library, only this is changed in a way that it clashes with libg++.
  729. This means that you'll need a patched version of libg++ for it to work.
  730.  
  731.    If you want to upgrade to a new gcc/libg++ combination, the easiest
  732. thing to do is to grab the prebuilt versions of gcc and libg++ for Linux
  733. from `ftp://tsx-11.mit.edu/pub/linux/packages/GCC'.  Follow the
  734. directions carefully.  If you want to build from source, you'll need a
  735. patch for libg++; the Linux developers have named the patched libg++
  736. version libg++-2.7.1.3 and there is a patch file in the above-named
  737. directory.
  738.  
  739.    See `ftp://www.mrc-apu.cam.ac.uk/pub/linux/GCC-FAQ.html', the Linux
  740. GCC FAQ (though it may be a bit out of date; the Linux community moves
  741. quickly).
  742.  
  743. Problems with g++ on Linux Slackware 3.0
  744. ========================================
  745.  
  746.    "When I try to compile the traditional Hello, world program on Linux,
  747. the compiler can't find `iostream.h'.  What's the deal?"
  748.  
  749.    You probably have the Slackware 3.0 release.  There's an error in the
  750. setup.  It's easy to fix, though; log in as root, and make a symbolic
  751. link:
  752.  
  753.      ln -s /usr/lib/g++-include /usr/include/g++
  754.  
  755. User Problems
  756. *************
  757.  
  758. Linker complains about missing virtual table
  759. ============================================
  760.  
  761.    "I'm getting a message complaining about an undefined virtual table.
  762. Is this a compiler bug?"
  763.  
  764.    (On platforms that run neither collect nor the GNU linker, like
  765. Solaris, you may see an odd undefined symbol like "_vt.3foo", where foo
  766. is a class name).
  767.  
  768.    This is probably because you are missing a definition for the first
  769. (non-inline) virtual function of the class.  Since gcc-2.7.0, g++ uses
  770. a trick borrowed from cfront: the .o file containing the definition for
  771. the first non-inline virtual function for the class will also contain
  772. the virtual function table.
  773.  
  774. gcc-2.7.0 breaks declarations in "for" statements!
  775. ==================================================
  776.  
  777.    gcc-2.7.0 implements the new ANSI/ISO rule on the scope of variables
  778. declared in for loops.
  779.  
  780.      for (int i = 1; i <= 10; i++) {
  781.              // do something here
  782.      }
  783.      foo(i);
  784.  
  785.    In the above example, most existing C++ compilers would pass the
  786. value 11 to the function `foo'.  In gcc 2.7 and in the ANSI/ISO working
  787. paper, the scope of `i' is only the for loop body, so this is an error.
  788. So that old code can be compiled, the new gcc has a flag
  789. `-fno-for-scope' that causes the old rule to be used.
  790.  
  791.    As of 2.7.1, the compiler attempts to issue warnings about code that
  792. has different meanings under the two sets of rules, but the code is not
  793. perfect: the intent was that code that has valid, but different,
  794. meanings under the ARM rules and the working paper rules would give
  795. warnings but have the new behavior, and this doesn't seem to happen.
  796.  
  797.    The `-ffor-scope' flag under 2.7.1 and 2.7.2 gives the 2.7.0
  798. behavior.
  799.  
  800. g++ seems to want a const constructor.  What's that?
  801. ====================================================
  802.  
  803.    gcc-2.7.1 introduced a bug that causes the compiler to ask for a
  804. const constructor (there's no such thing in C++) in certain situations
  805. where a const object appears in a template class.  Most cases have been
  806. fixed in gcc-2.7.2, but unfortunately not all.  Still, if you're running
  807. gcc-2.7.1 and have this problem, upgrade to 2.7.2; it is a vast
  808. improvement.
  809.  
  810.    The default constructor for the template `pair' in ObjectSpace's
  811. implementation of STL triggers the bug in one place, for gcc 2.7.2.  If
  812. you're using ObjectSpace<STL> and having this problem, simply change
  813. the default constructor from
  814.  
  815.      os_pair () : first (T1 ()), second (T2 ()) {}
  816.  
  817.    to just
  818.  
  819.      os_pair () {}
  820.  
  821.    Once this is done, ObjectSpace<STL> works fairly well.
  822.  
  823. How to silence "unused parameter" warnings
  824. ==========================================
  825.  
  826.    "When I use `-Wall' (or `-Wunused'), g++ warns about unused
  827. parameters.  But the parameters have to be there, for use in derived
  828. class functions.  How do I get g++ to stop complaining?"
  829.  
  830.    The answer is to simply omit the names of the unused parameters when
  831. defining the function.  This makes clear, both to g++ and to readers of
  832. your code, that the parameter is unused.  For example:
  833.  
  834.      int Foo::bar(int arg) { return 0; }
  835.  
  836.    will give a warning for the unused parameter `arg'.  To suppress the
  837. warning write
  838.  
  839.      int Foo::bar(int) { return 0; }
  840.  
  841. g++ objects to a declaration in a case statement
  842. ================================================
  843.  
  844.    "The compiler objects to my declaring a variable in one of the
  845. branches of a case statement.  Earlier versions used to accept this
  846. code.  Why?"
  847.  
  848.    The draft standard does not allow a goto or a jump to a case label to
  849. skip over an initialization of a variable or a class object.  For
  850. example:
  851.  
  852.      switch ( i ) {
  853.        case 1:
  854.          Object obj(0);
  855.              ...
  856.          break;
  857.        case 2:
  858.          ...
  859.          break;
  860.      }
  861.  
  862.    The reason is that `obj' is also in scope in the rest of the switch
  863. statement.
  864.  
  865.    As of version 2.7.0, the compiler will object that the jump to the
  866. second case level crosses the initialization of `obj'.  Older compiler
  867. versions would object only if class Object has a destructor.  In either
  868. case, the solution is to add a set of curly braces around the case
  869. branch:
  870.  
  871.        case 1:
  872.          {
  873.             Object obj(0);
  874.              ...
  875.             break;
  876.          }
  877.  
  878. Where can I find a demangler?
  879. =============================
  880.  
  881.    A g++-compatible demangler named `c++filt' can be found in the
  882. `binutils' distribution.  This distribution (which also contains the
  883. GNU linker) can be found at any GNU archive site.
  884.  
  885.    As of version 2.7.0, `c++filt' is included with gcc and is installed
  886. automatically.  Even better, it is used by the `collect' linker, so you
  887. don't see mangled symbols anymore.
  888.  
  889. Where can I find a version of etags for C++?
  890. ============================================
  891.  
  892.    The libg++ distribution contains a version of etags that works for
  893. C++ code.  Look in `libg++/utils'.  It's not built by default when you
  894. install libg++, but you can cd to that directory and type
  895.  
  896.      make etags
  897.  
  898.    after you've installed libg++.
  899.  
  900. Linker reports undefined symbols for static data members
  901. ========================================================
  902.  
  903.    "g++ reports undefined symbols for all my static data members when I
  904. link, even though the program works correctly for compiler XYZ.  What's
  905. going on?"
  906.  
  907.    The problem is almost certainly that you don't give definitions for
  908. your static data members.  If you have
  909.  
  910.      class Foo {
  911.          ...
  912.          void method();
  913.          static int bar;
  914.      };
  915.  
  916.    you have only declared that there is an int named Foo::bar and a
  917. member function named Foo::method that is defined somewhere.  You still
  918. need to define *both* method() and bar in some source file.  According
  919. to the draft ANSI standard, you must supply an initializer, such as
  920.  
  921.      int Foo::bar = 0;
  922.  
  923. in one (and only one) source file.
  924.  
  925. What does "Internal compiler error" mean?
  926. =========================================
  927.  
  928.    It means that the compiler has detected a bug in itself.
  929. Unfortunately, g++ still has many bugs, though it is a lot better than
  930. it used to be.  If you see this message, please send in a complete bug
  931. report (see next section).
  932.  
  933. I think I have found a bug in g++.
  934. ==================================
  935.  
  936.    "I think I have found a bug in g++, but I'm not sure.  How do I know,
  937. and who should I tell?"
  938.  
  939.    First, see the excellent section on bugs and bug reports in the gcc
  940. manual (which is included in the gcc distribution).  As a short summary
  941. of that section: if the compiler gets a fatal signal, for any input,
  942. it's a bug (newer versions of g++ will ask you to send in a bug report
  943. when they detect an error in themselves).  Same thing for producing
  944. invalid assembly code.
  945.  
  946.    When you report a bug, make sure to describe your platform (the type
  947. of computer, and the version of the operating system it is running) and
  948. the version of the compiler that you are running.  See the output of the
  949. command `g++ -v' if you aren't sure.  Also provide enough code so that
  950. the g++ maintainers can duplicate your bug.  Remember that the
  951. maintainers won't have your header files; one possibility is to send
  952. the output of the preprocessor (use `g++ -E' to get this).  This is
  953. what a "complete bug report" means.
  954.  
  955.    I will add some extra notes that are C++-specific, since the notes
  956. from the gcc documentation are generally C-specific.
  957.  
  958.    First, mail your bug report to "bug-g++@prep.ai.mit.edu".  You may
  959. also post to gnu.g++.bug, but it's better to use mail, particularly if
  960. you have any doubt as to whether your news software generates correct
  961. reply addresses.  Don't mail C++ bugs to bug-gcc@prep.ai.mit.edu.
  962.  
  963.    *News:* as I write this (late February 1996) the gateway connecting
  964. the bug-g++ mailing list and the gnu.g++.bug newsgroup is
  965. (temporarily?) broken.  Please mail, do not post bug reports.
  966.  
  967.    If your bug involves libg++ rather than the compiler, mail to
  968. bug-lib-g++@prep.ai.mit.edu.  If you're not sure, choose one, and if you
  969. guessed wrong, the maintainers will forward it to the other list.
  970.  
  971.    Second, if your program does one thing, and you think it should do
  972. something else, it is best to consult a good reference if in doubt.
  973. The standard reference is the draft working paper from the ANSI/ISO C++
  974. standardization committee, which you can get on the net.  For
  975. PostScript and PDF (Adobe Acrobat) versions, see the archive at
  976. `ftp://research.att.com/dist/stdc++/WP'.  For HTML and ASCII versions,
  977. see `ftp://ftp.cygnus.com/pub/g++'.  On the World Wide Web, see
  978. `http://www.cygnus.com/~mrs/misc/wp/'.
  979.  
  980.    An older standard reference is "The Annotated C++ Reference Manual",
  981. by Ellis and Stroustrup (copyright 1990, ISBN #0-201-51459-1).  This is
  982. what they're talking about on the net when they refer to "the ARM".
  983. But you should know that changes have been made to the language since
  984. then.
  985.  
  986.    The ANSI/ISO C++ standards committee have adopted some changes to the
  987. C++ language since the publication of the original ARM, and newer
  988. versions of g++ (2.5.x and later) support some of these changes, notably
  989. the mutable keyword (added in 2.5.0), the bool type (added in 2.6.0),
  990. and changes in the scope of variables defined in for statements (added
  991. in 2.7.0).  You can obtain an addendum to the ARM explaining many of
  992. these changes by FTP from
  993. `ftp://ftp.std.com/AW/stroustrup2e/new_iso.ps'.
  994.  
  995.    Note that the behavior of (any version of) AT&T's "cfront" compiler
  996. is NOT the standard for the language.
  997.  
  998. Porting programs from other compilers to g++
  999. ============================================
  1000.  
  1001.    "I have a program that runs on <some other C++ compiler>, and I want
  1002. to get it running under g++.  Is there anything I should watch out for?"
  1003.  
  1004.    Note that g++ supports many of the newer keywords that have recently
  1005. been added to the language.  Your other C++ compiler may not support
  1006. them, so you may need to rename variables and members that conflict
  1007. with these keywords.
  1008.  
  1009.    There are two other reasons why a program that worked under one
  1010. compiler might fail under another: your program may depend on the order
  1011. of evaluation of side effects in an expression, or it may depend on the
  1012. lifetime of a temporary (you may be assuming that a temporary object
  1013. "lives" longer than the standard guarantees).  As an example of the
  1014. first:
  1015.  
  1016.      void func(int,int);
  1017.      
  1018.      int i = 3;
  1019.      func(i++,i++);
  1020.  
  1021.    Novice programmers think that the increments will be evaluated in
  1022. strict left-to-right order.  Neither C nor C++ guarantees this; the
  1023. second increment might happen first, for example.  func might get 3,4,
  1024. or it might get 4,3.
  1025.  
  1026.    The second problem often happens with classes like the libg++ String
  1027. class.  Let's say I have
  1028.  
  1029.      String func1();
  1030.      void func2(const char*);
  1031.  
  1032.    and I say
  1033.  
  1034.      func2(func1());
  1035.  
  1036.    because I know that class String has an "operator const char*".  So
  1037. what really happens is
  1038.  
  1039.      func2(func1().convert());
  1040.  
  1041.    where I'm pretending I have a convert() method that is the same as
  1042. the cast.  This is unsafe in g++ versions before 2.6.0, because the
  1043. temporary String object may be deleted after its last use (the call to
  1044. the conversion function), leaving the pointer pointing to garbage, so by
  1045. the time func2 is called, it gets an invalid argument.
  1046.  
  1047.    Both the cfront and the old g++ behaviors are legal according to the
  1048. ARM, but the powers that be have decided that compiler writers were
  1049. given too much freedom here.
  1050.  
  1051.    The ANSI C++ committee has now come to a resolution of the lifetime
  1052. of temporaries problem: they specify that temporaries should be deleted
  1053. at end-of-statement (and at a couple of other points).  This means that
  1054. g++ versions before 2.6.0 now delete temporaries too early, and cfront
  1055. deletes temporaries too late.  As of version 2.6.0, g++ does things
  1056. according to the new standard.
  1057.  
  1058.    For now, the safe way to write such code is to give the temporary a
  1059. name, which forces it to live until the end of the scope of the name.
  1060. For example:
  1061.  
  1062.      String& tmp = func1();
  1063.      func2(tmp);
  1064.  
  1065.    Finally, like all compilers (but especially C++ compilers, it seems),
  1066. g++ has bugs, and you may have tweaked one.  If so, please file a bug
  1067. report (after checking the above issues).
  1068.  
  1069. Why does g++ mangle names differently from other C++ compilers?
  1070. ===============================================================
  1071.  
  1072.    See the answer to the next question.
  1073.  
  1074. Why can't g++ code link with code from other C++ compilers?
  1075. ===========================================================
  1076.  
  1077.    "Why can't I link g++-compiled programs against libraries compiled by
  1078. some other C++ compiler?"
  1079.  
  1080.    Some people think that, if only the FSF and Cygnus Support folks
  1081. would stop being stubborn and mangle names the same way that, say,
  1082. cfront does, then any g++-compiled program would link successfully
  1083. against any cfront-compiled library and vice versa.  Name mangling is
  1084. the least of the problems.  Compilers differ as to how objects are laid
  1085. out, how multiple inheritance is implemented, how virtual function
  1086. calls are handled, and so on, so if the name mangling were made the
  1087. same, your programs would link against libraries provided from other
  1088. compilers but then crash when run.  For this reason, the ARM
  1089. *encourages* compiler writers to make their name mangling different
  1090. from that of other compilers for the same platform.  Incompatible
  1091. libraries are then detected at link time, rather than at run time.
  1092.  
  1093. What documentation exists for g++ 2.x?
  1094. ======================================
  1095.  
  1096.    Relatively little.  While the gcc manual that comes with the
  1097. distribution has some coverage of the C++ part of the compiler, it
  1098. focuses mainly on the C compiler (though the information on the "back
  1099. end" pertains to C++ as well).  Still, there is useful information on
  1100. the command line options and the #pragma interface and #pragma
  1101. implementation directives in the manual, and there is a useful section
  1102. on template instantiation in the 2.6 version.  There is a Unix-style
  1103. manual entry, "g++.1", in the gcc-2.x distribution; the information
  1104. here is a subset of what is in the manual.
  1105.  
  1106.    You can buy a nicely printed and bound copy of this manual from the
  1107. FSF; see above for ordering information.
  1108.  
  1109.    For versions 2.6.2 and later, the gcc/g++ distribution contains the
  1110. gcc manual in PostScript.  Also, Postscript versions of GNU
  1111. documentation in U.S. letter format are available by anonymous FTP from
  1112. `ftp://primus.com/pub/gnu-ps'.  The same, in A4 format, are on
  1113. `ftp://liasun3.epfl.ch/pub/gnu/ps-doc'.
  1114.  
  1115.    A draft of a document describing the g++ internals appears in the gcc
  1116. distribution (called g++int.texi); it is incomplete but gives lots of
  1117. information.
  1118.  
  1119. Problems with the template implementation
  1120. =========================================
  1121.  
  1122.    g++ does not implement a separate pass to instantiate template
  1123. functions and classes at this point; for this reason, it will not work,
  1124. for the most part, to declare your template functions in one file and
  1125. define them in another.  The compiler will need to see the entire
  1126. definition of the function, and will generate a static copy of the
  1127. function in each file in which it is used.
  1128.  
  1129.    (The experimental template repository code (see *Note repository::)
  1130. that can be added to 2.7.0 or later does implement a separate pass, but
  1131. there is still no searching of files that the compiler never saw).
  1132.  
  1133.    For version 2.6.0, however, a new switch `-fno-implicit-templates'
  1134. was added; with this switch, templates are expanded only under user
  1135. control.  I recommend that all g++ users that use templates read the
  1136. section "Template Instantiation" in the gcc manual (version 2.6.x and
  1137. newer).  g++ now supports explicit template expansion using the syntax
  1138. from the latest C++ working paper:
  1139.  
  1140.      template class A<int>;
  1141.      template ostream& operator << (ostream&, const A<int>&);
  1142.  
  1143.    As of version 2.6.3, there are still a few limitations in the
  1144. template implementation besides the above (thanks to Jason Merrill for
  1145. this info): These are still present in version 2.7.2, but a new
  1146. implementation of templates planned for version 2.8 will eliminate them.
  1147.  
  1148.   1. Static data member templates are not supported.  You can work
  1149.      around this by explicitly declaring the static variable for each
  1150.      template specialization:
  1151.  
  1152.           template <class T> struct A {
  1153.             static T t;
  1154.           };
  1155.           
  1156.           template <class T> T A<T>::t = 0; // gets bogus error
  1157.           int A<int>::t = 0;                // OK (workaround)
  1158.  
  1159.      (still a limitation in 2.7.2)
  1160.  
  1161.   2. Template member names are not available when defining member
  1162.      function templates.
  1163.  
  1164.           template <class T> struct A {
  1165.             typedef T foo;
  1166.             void f (foo);
  1167.             void g (foo arg) { ... }; // this works
  1168.           };
  1169.           
  1170.           template <class T> void A<T>::f (foo) { } // gets bogus error
  1171.  
  1172.   3. Templates are instantiated using the parser.  This results in two
  1173.      problems:
  1174.  
  1175.      a) Class templates are instantiated in some situations where such
  1176.      instantiation should not occur.
  1177.  
  1178.           template <class T> class A { };
  1179.           A<int> *aip = 0; // should not instantiate A<int> (but does)
  1180.  
  1181.      b) Function templates cannot be inlined at the site of their
  1182.      instantiation.
  1183.  
  1184.           template <class T> inline T min (T a, T b) { return a < b ? a : b; }
  1185.           
  1186.           void f () {
  1187.             int i = min (1, 0);           // not inlined
  1188.           }
  1189.           
  1190.           void g () {
  1191.             int j = min (1, 0);           // inlined
  1192.           }
  1193.  
  1194.      A workaround that works in version 2.6.1 and later is to specify
  1195.  
  1196.           extern template int min (int, int);
  1197.  
  1198.      before `f()'; this will force it to be instantiated (though not
  1199.      emitted).
  1200.  
  1201.   4. Member function templates are always instantiated when their
  1202.      containing class is.  This is wrong.
  1203.  
  1204. I get undefined symbols when using templates
  1205. ============================================
  1206.  
  1207.    (Thanks to Jason Merrill for this section).
  1208.  
  1209.    g++ does not automatically instantiate templates defined in other
  1210. files.  Because of this, code written for cfront will often produce
  1211. undefined symbol errors when compiled with g++.  You need to tell g++
  1212. which template instances you want, by explicitly instantiating them in
  1213. the file where they are defined.  For instance, given the files
  1214.  
  1215.    `templates.h':
  1216.      template <class T>
  1217.      class A {
  1218.      public:
  1219.        void f ();
  1220.        T t;
  1221.      };
  1222.      
  1223.      template <class T> void g (T a);
  1224.  
  1225.    `templates.cc':
  1226.      #include "templates.h"
  1227.      
  1228.      template <class T>
  1229.      void A<T>::f () { }
  1230.      
  1231.      template <class T>
  1232.      void g (T a) { }
  1233.  
  1234.    main.cc:
  1235.      #include "templates.h"
  1236.      
  1237.      main ()
  1238.      {
  1239.        A<int> a;
  1240.        a.f ();
  1241.        g (a);
  1242.      }
  1243.  
  1244.    compiling everything with `g++ main.cc templates.cc' will result in
  1245. undefined symbol errors for `A<int>::f ()' and `g (A<int>)'.  To fix
  1246. these errors, add the lines
  1247.  
  1248.      template class A<int>;
  1249.      template void g (A<int>);
  1250.  
  1251.    to the bottom of `templates.cc' and recompile.
  1252.  
  1253. I get multiply defined symbols using templates
  1254. ==============================================
  1255.  
  1256.    You may be running into a bug that was introduced in version 2.6.1
  1257. (and is still present in 2.6.3) that generated external linkage for
  1258. templates even when neither `-fexternal-templates' nor
  1259. `-fno-implicit-templates' is specified.  There is a patch for this
  1260. problem at
  1261. `ftp://ftp.cygnus.com/pub/g++/gcc-2.6.3-template-fix'.
  1262.  
  1263.    I recommend either applying the patch or using
  1264. `-fno-implicit-templates' together with explicit template instantiation
  1265. as described in previous sections.
  1266.  
  1267.    This bug is fixed in 2.7.0.
  1268.  
  1269. Does g++ support the Standard Template Library?
  1270. ===============================================
  1271.  
  1272.    From Per Bothner:
  1273.  
  1274.    The Standard Template Library (STL) uses many of the extensions that
  1275. the ANSI/ISO committee has made to templates, and g++ doesn't support
  1276. some of these yet.  So if you grab HP's free implementation of STL it
  1277. isn't going to work.  However, starting with libg++-2.6.2 libg++
  1278. contains a hacked version of STL, based on work by Carsten Bormann,
  1279. which permits g++ to compile at least the containers.  A full
  1280. implementation is going to need improved template support, which will
  1281. take a while yet (2.8.0 will compile the HP version successfully).
  1282.  
  1283.    Actually, the hacked STL and gcc-2.7.2 work quite well; I've
  1284. succeeded in making significant use of it.  Almost all of the
  1285. ObjectSpace examples (a set of over 200 simple examples of STL usage)
  1286. now work.
  1287.  
  1288.    There are several commercial suppliers of STL implementations;
  1289. ObjectSpace's version supports gcc-2.7.x.
  1290.  
  1291.    Mumit Khan has produced an "STL newbie guide" with lots of
  1292. information on using STL with gcc.  See
  1293.  
  1294.    `http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html'
  1295.  
  1296. What are the differences between g++ and the ARM specification of C++?
  1297. ======================================================================
  1298.  
  1299.    As of version 2.7.0, g++ has exception support on most but not all
  1300. platforms (no support on MIPS-based platforms yet), but it doesn't work
  1301. right if optimizaton is enabled, which means the exception
  1302. implementation is still not really ready for production use.
  1303.  
  1304.    Some features that the ANSI/ISO standardization committee has voted
  1305. in that don't appear in the ARM are supported, notably the `mutable'
  1306. keyword, in version 2.5.x.  2.6.x adds support for the built-in boolean
  1307. type `bool', with constants `true' and `false'.  The beginnings of
  1308. run-time type identification are present, so there are more reserved
  1309. words: `typeid', `static_cast', `reinterpret_cast', `const_cast', and
  1310. `dynamic_cast'.
  1311.  
  1312.    As with any beta-test compiler, there are bugs.  You can help improve
  1313. the compiler by submitting detailed bug reports.
  1314.  
  1315.    One of the weakest areas of g++ other than templates is the
  1316. resolution of overloaded functions and operators in complex cases.  The
  1317. usual symptom is that in a case where the ARM says that it is ambiguous
  1318. which function should be chosen, g++ chooses one (often the first one
  1319. declared).  This is usually not a problem when porting C++ code from
  1320. other compilers to g++, but shows up as errors when code developed under
  1321. g++ is ported to other compilers.  (I believe this is no longer a
  1322. significant problem in 2.7.0).
  1323.  
  1324.    [A full bug list would be very long indeed, so I won't put one here.
  1325. I may add a list of frequently-reported bugs and "non-bugs" like the
  1326. static class members issue mentioned above].
  1327.  
  1328. Will g++ compile InterViews?  The NIH class library?  Rogue Wave?
  1329. =================================================================
  1330.  
  1331.    The NIH class library uses a non-portable, compiler-dependent hack
  1332. to initialize itself, which makes life difficult for g++ users.  It
  1333. will not work without modification, and I don't know what modifications
  1334. are required or whether anyone has done them successfully.
  1335.  
  1336.    In short, it's not going to happen any time soon (previous FAQs
  1337. referred to patches that a new NIHCL release would hopefully contain,
  1338. but this hasn't happened).
  1339.  
  1340.    *Note:* I thought I saw an item indicating that someone *had*
  1341. patched NIHCL to work with g++.  Any pointers?
  1342.  
  1343.    I think that as of version 2.5.6, the standard g++ will compile the
  1344. standard 3.1 InterViews completely successfully.  Note that you'll need
  1345. the `-fno-for-scope' flag if you use gcc-2.7.0; with 2.7.2 you may be
  1346. able to omit this flag but you'll get warnings.
  1347.  
  1348.    According to Jason Merrill, gcc-2.7.0 and newer works with Rogue
  1349. Wave's `tools.h++' class library, but you may want to grab
  1350. `ftp://ftp.cygnus.com/pub/g++/Tools.h++-6.1-patch'.  Again, you'll need
  1351. the `-fno-for-scope' flag since Rogue Wave hasn't fixed their code to
  1352. comply with the new standard yet.
  1353.  
  1354. Debugging on SVR4 systems
  1355. =========================
  1356.  
  1357.    "How do I get debugging to work on my System V Release 4 system?"
  1358.  
  1359.    Most systems based on System V Release 4 (except Solaris) encode
  1360. symbolic debugging information in a format known as `DWARF'.
  1361.  
  1362.    Although the GNU C compiler already knows how to write out symbolic
  1363. debugging information in the DWARF format, the GNU C++ compiler does
  1364. not yet have this feature, nor is it likely to in the immediate future.
  1365.  
  1366.    Ron Guilmette has done a great deal of work to try to get the GNU
  1367. C++ compiler to produce DWARF format symbolic debugging information
  1368. (for C++ code) but he gave up on the project because of a lack of
  1369. funding and/or interest from the g++ user community.  If you have a
  1370. strong desire to see this project completed, contact Ron at
  1371. <rfg@netcom.com>.
  1372.  
  1373.    In the meantime, you *can* get g++ debugging under SVR4 systems by
  1374. configuring gcc with the `--with-stabs' option.  This causes gcc to use
  1375. an alternate debugging format, one more like that used under SunOS4.
  1376. You won't need to do anything special to GDB; it will always understand
  1377. the "stabs" format.
  1378.  
  1379. X11 conflicts with libg++ in definition of String
  1380. =================================================
  1381.  
  1382.    "X11 and Motif define String, and this conflicts with the String
  1383. class in libg++.  How can I use both together?"
  1384.  
  1385.    One possible method is the following:
  1386.  
  1387.      #define String XString
  1388.      #include <X11/Intrinsic.h>
  1389.      /* include other X11 and Motif headers */
  1390.      #undef String
  1391.  
  1392.    and remember to use the correct `String' or `XString' when you
  1393. declare things later.
  1394.  
  1395. Why can't I assign one stream to another?
  1396. =========================================
  1397.  
  1398.    [ Thanks to Per Bothner and Jerry Schwarz for this section. ]
  1399.  
  1400.    Assigning one stream to another seems like a reasonable thing to do,
  1401. but it's a bad idea.  Usually, this comes up because people want to
  1402. assign to `cout'.  This is poor style, especially for libraries, and is
  1403. contrary to good object-oriented design.  (Libraries that write directly
  1404. to `cout' are less flexible, modular, and object-oriented).
  1405.  
  1406.    The iostream classes do not allow assigning to arbitrary streams,
  1407. because this can violate typing:
  1408.  
  1409.      ifstream foo ("foo");
  1410.      istrstream str(...);
  1411.      foo = str;
  1412.      foo->close ();  /* Oops! Not defined for istrstream! */
  1413.  
  1414.    The original cfront implementation of iostreams by Jerry Schwarz
  1415. allows you to assign to `cin', `cout', `cerr', and `clog', but this is
  1416. not part of the draft standard for iostreams and generally isn't
  1417. considered a good idea, so standard-conforming code shouldn't use this
  1418. technique.
  1419.  
  1420.    The GNU implementation of iostream did not support assigning to
  1421. `cin', `cout', `cerr', and `clog' for quite a while, but it now does,
  1422. for backward compatibility with cfront iostream (versions 2.6.1 and
  1423. later of libg++).
  1424.  
  1425.    The ANSI/ISO C++ Working Paper does provide ways of changing the
  1426. streambuf associated with a stream.  Assignment isn't allowed; there is
  1427. an explicit named member that must be used.
  1428.  
  1429.    However, it is not wise to do this, and the results are confusing.
  1430. For example: `fstream::rdbuf' is supposed to return the *original*
  1431. filebuf, not the one you assigned. (This is not yet implemented in GNU
  1432. iostream.)  This must be so because `fstream::rdbuf' is defined to
  1433. return a `filebuf *'.
  1434.  
  1435. What are the rules for shipping code built with g++ and libg++?
  1436. ***************************************************************
  1437.  
  1438.    "Is it is possible to distribute programs for profit that are created
  1439. with g++ and use the g++ libraries?"
  1440.  
  1441.    I am not a lawyer, and this is not legal advice.  In any case, I have
  1442. little interest in telling people how to violate the spirit of the GNU
  1443. licenses without violating the letter.  This section tells you how to
  1444. comply with the intention of the GNU licenses as best I understand them.
  1445.  
  1446.    The FSF has no objection to your making money.  Its only interest is
  1447. that source code to their programs, and libraries, and to modified
  1448. versions of their programs and libraries, is always available.
  1449.  
  1450.    The short answer is that you do not need to release the source to
  1451. your program, but you can't just ship a stripped executable either,
  1452. unless you use only the subset of libg++ that includes the iostreams
  1453. classes (see discussion below) or the new libstdc++ library (available
  1454. in libg++ 2.6.2 and later).
  1455.  
  1456.    Compiling your code with a GNU compiler does not affect its
  1457. copyright; it is still yours.  However, in order to ship code that
  1458. links in a GNU library such as libg++ there are certain rules you must
  1459. follow.  The rules are described in the file COPYING.LIB that
  1460. accompanies gcc distributions; it is also included in the libg++
  1461. distribution.  See that file for the exact rules.  The agreement is
  1462. called the Library GNU Public License or LGPL.  It is much "looser"
  1463. than the GNU Public License, or GPL, that covers must GNU programs.
  1464.  
  1465.    Here's the deal: let's say that you use some version of libg++,
  1466. completely unchanged, in your software, and you want to ship only a
  1467. binary form of your code.  You can do this, but there are several
  1468. special requirements.  If you want to use libg++ but ship only object
  1469. code for your code, you have to ship source for libg++ (or ensure
  1470. somehow that your customer already has the source for the exact version
  1471. you are using), and ship your application in linkable form.  You cannot
  1472. forbid your customer from reverse-engineering or extending your program
  1473. by exploiting its linkable form.
  1474.  
  1475.    Furthermore, if you modify libg++ itself, you must provide source
  1476. for your modifications (making a derived class does not count as
  1477. modifying the library - that is "a work that uses the library").
  1478.  
  1479.    For certain portions of libg++ that implement required parts of the
  1480. C++ language (such as iostreams and other standard classes), the FSF has
  1481. loosened the copyright requirement still more by adding the "special
  1482. exception" clause, which reads as follows:
  1483.  
  1484.      As a special exception, if you link this library with files
  1485.      compiled with GCC to produce an executable, this does not cause
  1486.      the resulting executable to be covered by the GNU General Public
  1487.      License.  This exception does not however invalidate any other
  1488.      reasons why the executable file might be covered by the GNU
  1489.      General Public License.
  1490.  
  1491.    If your only use of libg++ uses code with this exception, you may
  1492. ship stripped executables or license your executables under different
  1493. conditions without fear of violating an FSF copyright.  It is the intent
  1494. of FSF and Cygnus that, as the other classes required by the ANSI/ISO
  1495. draft standard are developed, these will also be placed under this
  1496. "special exception" license.  The code in the new libstdc++ library,
  1497. intended to implement standard classes as defined by ANSI/ISO, is also
  1498. licensed this way.
  1499.  
  1500.    To avoid coming under the influence of the LGPL, you can link with
  1501. `-liostream' rather than `-lg++' (for version 2.6.x and earlier), or
  1502. `-lstdc++' now that it is available.  In version 2.7.0 all the standard
  1503. classes are in `-lstdc++'; you can do the link step with `c++' instead
  1504. of `g++' to search only the `-lstdc++' library and avoid the LGPL'ed
  1505. code in `-lg++'.
  1506.  
  1507. -- 
  1508. -- Joe Buck     <jbuck@synopsys.com>    (not speaking for Synopsys, Inc)
  1509.  
  1510. Work for something because it is good,
  1511. not just because it stands a chance to succeed.       -- Vaclav Havel
  1512.